Adding the console appender to the root logger won’t make logs from loggers with additivity="false" appear in docker logs. In this config, com.alipay.sofa (and other explicitly configured loggers) only write to raft_file/file, so raft/third‑party logs will still be missing from stdout. Consider also adding a console appender-ref to those additivity=false loggers (or revisiting additivity) to fully achieve the Docker logging goal.

As with the other dist configs, adding console to <root> won’t surface logs from any additivity="false" loggers that only write to raft_file/file. If the goal is comprehensive docker logs output, consider also wiring console into those additivity=false logger definitions (this matches the wiring used in hg-pd-service/src/main/resources/log4j2.xml).

‼️ The same completeness gap exists here too: root now has console, but com.alipay.sofa, io.netty, and org.apache.commons still short-circuit to file only because their logger blocks keep additivity="false". Container logs will still miss transport/startup output unless those explicit loggers also opt into console.

‼️ Same issue in the store config: the root console appender does not cover the additivity="false" logger blocks below, so io.netty / org.apache.commons / com.alipay.sofa output is still invisible in docker logs. If the goal is a complete container stream, those explicit loggers need console as well.

‼️ Adding console only to root and org.apache.hugegraph is not enough here: the additivity="false" logger blocks below still bind only file, so startup/runtime messages from org.apache.cassandra, io.netty, com.datastax.driver, com.alipay.sofa, etc. will still be absent from docker logs. Please attach console to the explicit logger blocks that should be visible in containers.

‼️ Removing the launcher redirection here changes the default binary-package flow too. In a plain install, JVM bootstrap stdout/stderr will no longer land in the logs/*.log file, so the docs that tell users to inspect that file on failure become incomplete. Please gate this on the Docker entrypoint path or preserve the file sink outside containers.

The safer, lower-risk approach is to add an explicit switch for Docker/stdout mode instead of removing >> ${OUTPUT} 2>&1 from the default startup path.

That keeps the binary-package flow unchanged and still lets containers stream clean logs via docker logs when the switch is enabled.

Default package: start-*.sh -> exec java -> >> logs/*.log 2>&1

Docker package:   entrypoint -> set STDOUT_MODE=true -> exec java -> stdout + console appender

I would keep the file-based behavior by default, then enable stdout only in the Docker entrypoint and wire the console appender in the matching log config.